LEKCJA SZÓSTA

Faza V : Projektowanie perspektyw

Powoli zbliżamy się do końca projektowanie "logiki" bazy danych. Zaprojektowaliśmy już pola, tabele, relacje i reguły integralności. Mamy podstawy do rozpoczęcia kolejnej fazy - projektowania perspektyw. Perspektywy w rzeczywistości nie istnieją są tworami wirtualnymi, powstałymi na chwilę w pamięci komputera na podstawie danych z rzeczywistych tabel bazy po zadaniu odpowiedniego zapytania (nazywanego w Accessie kwerendą). Podobnie jak poprzednie fazy, również i ta wymaga wnikliwego "rozpoznania tematu". Aby zaprojektować zestaw perspektyw, musimy wiedzieć dokładnie, do czego mają służyć. Wiele formularzy i raportów tworzy je na podstawie perspektyw opartych na danych z kilku tabel.

Przyda się wstępna lista pól wyliczonych, wcześniejsze, rozmowy z przyszłymi użytkownikami buzy, wszelkiego rodzaju papierowa dokumentacja firmy. Perspektywy można podzielić na kilku kategorii:

- danych : wykorzystywane są do przeglądania i modyfikowania danych. Pola perspektywy mogą pochodzić z pojedynczej tabeli, kilku tabel połączonych relacją a nawet z innych perspektyw lub połączenia tabel i perspektyw. Cechą perspektyw danych jest niekiedy brak klucza podstawowego. Perspektywa nie musi mieć klucza, ponieważ w rzeczywistości nie istnieje.

- agregujące : zawierają jedno lub więcej pól wyliczonych, stanowiących wynik agregacji danych oraz jedno lub więcej pól mających za zadanie pogrupowanie pól agregowanych. Funkcje agregujące to najczęściej suma, średnia, minimum, maksimum oraz liczba elementów.

- walidacji : służą do tych samych celów, do których służą tabele walidacji -ograniczenia danych możliwych da przeglądania czy modyfikowania. Różnica polega na ich budowie - tabelę walidacji należy mieć już gotową, zdefiniowaną, podczas gdy perspektywy walidacji pobierają dynamicznie dane z istniejących tabel. Najczęściej służą do ograniczenia użytkownikom dostępu do pewnych danych.

W naszym konkretnym przypadku najbardziej istotne są następujące perspektywy:

- umożliwiające wprowadzanie (i usuwanie) nowych pozycji

- analiza pod względem różnych kryteriów

- druk bibliografii

Faza VI : Kontrola integralności danych

Służy ostatecznej kontroli integralności bazy danych. Mimo sumiennego przestrzegania zaleceń, zawsze może się zdarzyć jakiś błąd projektowy. Podczas tej końcowej fazy ponownie zwracamy uwagę na kontrolę integralności na poziomie tabel, pól, relacji, reguł integralności i perspektyw. Na poziomie tabel sprawdzamy, czy tabela nic zawiera pól segmentowych, wielowartościowych, wyliczonych, zdublowanych oraz czy klucz podstawowy jest dobrze zdefiniowany. Na poziomie pól sprawdzamy, czy każde pole ma określony zestaw atrybutów. Na poziomie relacji kontrolujemy ponownie, czy relacje zostały poprawnie zdefiniowane oraz jak określono reguły usuwania rekordów z tabeli. Na poziomie reguł integralności testujemy, czy zostały wprowadzone odpowiednie tabele walidacji, czy zostały logicznie określone ograniczenia wartości pól. Na poziomie perspektyw upewniamy się, czy perspektywy bazują na odpowiednich tabelach, czy pola wyliczone są dobrze zdefiniowane, jak również czy działają określone reguły filtrowania danych wyświetlanych w perspektywie.

Wreszcie nadszedł koniec tego etapu projektowania bazy danych. Możemy stwierdzić z dużą dozą prawdopodobieństwa, że logika bazy naprawdę jest dobrze zaprojektowana.

Projektowanie struktury programu obsługi bazy danych

Po zaprojektowaniu całej logiki bazy danych mamy gotowy rdzeń bazy, dzięki któremu wiemy, jakie tabele, kwerendy będzie zawierać baza danych w momencie jej fizycznego tworzenia.

W drugim etapie staramy się wyliczyć wszystkie istotne formularze i raporty, mające znależć, się w naszej aplikacji. Musimy określić, jak będzie wyglądało w programie przełączanie się pomiędzy poszczególnymi formularzami i raportami. Oczywiście do tego jako całość można zaprojektować panel sterowania (będący formularzem) rozpoczynający i kończący całą aplikację.

Szczegółowe omówienie funkcji poszczególnych formularzy i raportów w tym miejscu pracy mija się z celem, jakim było jedynie zaznaczenie potrzeby tego etapu projektowania aplikacji. Tworzenie tabel, kwerend, formularzy można w większości przypadków zlecić Kreatorom, które wykonają za nas czarną robotę (w środowisku Access).